The life cycle of software generally starts with the implementation phase that consists of blueprint, configuration and testing. After the test phase, the software is used productively in the operations phase where administrative tasks, monitoring and services are performed. If a productive system is upgraded, the blueprint has to be adapted and the life-cycle starts again.
In the first stage of the blueprint phase customers define their scenarios, processes, master data objects, and organizational units, referred to herein as structure objects. These structure objects as well as associated objects (e.g., documents, configuration items, test cases, etc.) assigned to the structure objects are subject to changes during the life-cycle. If one phase (e.g., blueprint) is finished, changes to the structure objects as well as changes to associated objects are generally not tracked. This may cause several problems.
For example, the blueprint defines the scope of a project. At the end of the blueprint phase, the blueprint is frozen and a blueprint document is generated to document the scope of the blueprint. The budget for subsequent phases is based on the information in the blueprint. After the blueprint phase, the project enters a configuration phase. While in the configuration phase, it might become necessary to go back and make changes to the blueprint. Similarly while in a testing phase, it might become necessary to go back and make changes to the configuration phase. This example scenario can exist between any two phases of a software life cycle. The problem, however, is that in traditional change management systems there is no way to request, approve, decline and/or track changes to structure objects in a previously completed phase.